Business Analyst Community & Resources | Modern Analyst

What sort of existing documents should Business Analysts refer to when starting on a new project?

everest — Sat, 08 Dec 2018 21:21:00 GMT

Few analysts are brought on to a project at the very beginning. For those that are, they will often have a hand in creating some of the important documents that other analysts should reference when they first join.

What is use case generalization?

everest — Tue, 27 May 2008 18:10:00 GMT

In the context of use case modeling the use case generalization refers to the relationship which can exist between two use cases and which shows that one use case (child) inherits the structure, behavior, and relationships of another actor (parent). The child use case is also referred to the more specialized use case while the parent is also referred to as the more abstract use case of the relationship.

For those of you familiar with object oriented concepts: use cases in UML are classes and the generalization is simply the inheritance relationship between two use cases by which one use case inherits all the properties and relationships of another use case.

You can use the generalization relationship when you find two or more use cases which have common behavior/logic. In this instance, you can describe the common parts in a separate use case (the parent) which then is specialized into two or more specialized child use cases.

Example:

If you are creating a payment system which allows students of a training provider to pay for courses both on-line and by phone, there will many things in common between the two scenarios: specifying personal info, specifying payment info, etc. However, there would also be differences between the two. So, the best way to accomplish this is to create one use case (the parent) which contains the common behavior and then create two specialized child use cases which inherit from the parent and which contain the differences specific to registering on-line vs. by phone.

What is actor generalization?

everest — Tue, 27 May 2008 17:18:00 GMT

In the context of use case modeling the actor generalization refers to the relationship which can exist between two actors in a use case diagram and which shows that one actor (descendant) inherits the role and properties of another actor (ancestor). The generalization relationship also implies that the descendant actor can use all the use cases that have been defined for its ancestor.

For those of you familiar with object oriented concepts: actors in UML are classes and the generalization is simply the inheritance relationship between two actors by which one actor inherits all the properties and relationships of another actor.

Example 1:

When it comes to air travel, both a "Business Traveler" and a "Tourist" are "Passengers". The fact that they are passengers allow them to have common behavior such as "Buy Ticket" but the fact that they are separate actors implies they can also have differences. The "Business Traveler" might be able to "Redeem Business Miles" while the "Tourist" cannot.

Example 2:

Another scenario often found in many systems is when the system administrator, who gets additional functionality, is actually one of the normal users. So let's say that the system is an accounting system with the main actor being "Accountant" and with another actor called "Administrator". In our scenarios the Administrator should be able to perform all the normal accounting functions in addition to his/her administrator role.

The way to model this would be to show relationships between the Administrator actor and all the admin only use cases, then show all the accounting specific use cases related to the "Accountant" actor. And now, the only other thing you need to do for the "Administrator" to have access to the accounting features is to use the generalization relationship between the "Accountant" and the "Administrator" with the Administrator actor (descendant) inheriting from the Accountant actor (the ancestor).

Are use cases the functional requirements or do you think functional requirements are different from use cases?

everest — Fri, 02 May 2008 03:29:00 GMT

It is generally accepted that use cases, specified in narrative form (also known as use case specifications), depict functional requirements. This is because a use case, via the main and alternate flows, shows how a user interacts with a system in order to achieve a desired result.

That's exactly the purpose of a "functional requirement" to describe the functions and behaviors that a system is or should be capable of.

Therefore, if use cases are used and narrated in detail for a project, there is no need for separate documentation to describe the functional requirements because the totality of all the use cases represent the set of functional requirements for a given system/project.